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REMARKS 



In response to the Notice to File Corrected Application Papers mailed on May 31, 
2001, Applicant submitted and filed substitute drawings in compliance with 37 C.F.R. § 
1.84 on July 26, 2001. 

In the substitute drawings, Figures 6, 24, 28 and 29 were divided into multiple 
drawings for convenience, and Figures 18, 25, 26 and 27 were divided into additional 
multiple drawings for this same reason. The changes to the drawings necessitated 
amending the references to the drawings in the specification in order to bring the 
specification into harmony with the drawings. Therefore, the specification has been 
amended and corrected throughout the application to clarify and consistently refer to 
Figures 6, 18 and 24 through 29. Applicant respectfully submits that the correction of 
the references to the drawings in the specification adds no new matter to the present 
application. 

Applicant corrected an inadvertent error on page 26, line 14, by adding the 
phrase "at step 2" between the words "604" and "and". Applicant respectfully submits 
that this correction adds no new matter to the present application. 

Finally, Applicant corrected a typographical error in the paragraph beginning at 
page 8, line 15, and ending at line 18, by changing "Oobject" to "object". 
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Applicant respectfully requests the entry and approval of the foregoing 
amendments prior to examination. 

No amendment made was related to the statutory requirements of patentability 
unless expressly stated herein. 

No amendment made was for the purpose of narrowing the scope of any claim, 
unless Applicant has argued herein that such amendment was a narrowing amendment 
made to distinguish over a specified reference or references. 

The Commissioner is hereby authorized to charge payment of any additional 
filing or application fees associated with this communication or credit any overpayment 
to Deposit Account No. 13-4365. 

Attached hereto is a marked-up version of the changes made to the claims by 
the current amendment. The attached page is captioned " Version with markings to 
show changes made. " 
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If there are any questions regarding these amendments, please do not hesitate 



to contact us. 



Respectfully submitted, 




Dated: August 27, 2001 



Charles L. Evans 



Attorney for Applicants 
Registration No. 40,380 
Moore & Van Allen PLLC 
2200 West Main Street, Suite 800 
Durham, NC 27705 
Telephone: (919) 286-8000 
Facsimile: (919)286-8199 
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VERSION WITH MARKINGS TO SHOW CHANGES MADE 

IN THE SPECIFICATION 

The paragraph beginning at page 6, line 20, and ending at line 21, has been 
amended as follows: 

FIG. 6 illustrates a method of distributing and federating metadata 
across a distributed network according to an embodiment of the invention. 
FIG. 6 is divided into Figures 6-A and 6-B for convenience. 

The paragraph beginning at page 8, line 6, and ending at line 8, has been 
amended as follows: 

FIG. 18 is an activity diagram depicting the flow of events involved 
in utilizing a push agent to send data to the server in one embodiment of 
the invention. FIG. 18 is divided into Figures 18-A through[and] 18-C f18- 
B] for convenience. 

The paragraph beginning at page 8, line 15, and ending at line 18, has been 
amended as follows: 
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FIG. 22 is a block diagram, which illustrates the structure used and 
method for analyzing patient demographic data and correlating it against 
existing information to create or update a universal person obiect rOobjectl 
according to one embodiment of the invention. 



The six paragraphs beginning at page 9, line 1, and ending at line 17, have been 
amended as follows: 



FIG. 24 provides an XML document type definition (DTD) used to 
describe the message envelope and the payload containers transmitted to 
the system in the write metadata transaction. FIG. 24 is divided into 
Figures 24-A and 24-B for convenience. 



FIG. 25 provides the XML DTD used to describe the data 
transmitted in the write metadata transaction. FIG. 25 is divided into 
Figures 25-A through 25-J r25-G1 for convenience. 

FIG. 26 provides the XML DTD used to describe the data 
transmitted in delete metadata transaction according to one embodiment 
of the invention. FIG. 26 is divided into Figures 26-A through 26-F f26-D1 
for convenience. 
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FIG. 27 provides the XML DTD used to describe the data 
transmitted in merge metadata transaction according to one embodiment 
of the invention. FIG. 27 is divided into Figures 27-A through 27-J r27-Gl 
for convenience. 

FIG. 28 illustrates the class hierarchy for a universal person object 
for identifying and finding patients, their providers and the organizations 
that have provided treatment according to one embodiment of the 
invention. FIG. 28 is divided into Figures 28-A and 28-B for convenience. 

FIG. 29 is a detailed sequence diagram showing how queries are 
processed according to one embodiment of the invention. FIG. 29 is 
divided into Figures 29-A and 29-B for convenience. 

The paragraph beginning at page 26, line 7, and ending at line 16, has been 
amended as follows: 

FIG. 6 extends the functionality described above to allow federation 
of identifiers across multiple domains. FIG. 6 is divided into Figures 6-A 
and 6-B for convenience. In this schema, a local exchange server, 604, 
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correlates patients across a number of systems within a local domain. At 
step 1 information is sent to the local server by a clinical system such as a 
pharmacy system, 601 , a laboratory system, 602, or a radiology system, 
603. A local universal person object is created and then forwarded to the 
parent, the domain exchange server, 606, in its hierarchy. The parent can 
receive data from multiple local exchange servers such as shown at 605. 
The parent now knows that it can query local exchange server 604 at step 
2_and ask for information about a patient and the local exchange server 
will subsequently query each of its subsystems to find records for the 
patient. 



The paragraph beginning at page 38, line 3, and ending at line 12, has been 
amended as follows: 



FIG. 18 is a sequence diagram describing how an external clinical 
system requests service from the exchange. FIG. 18 is divided into 
Figures 18-A . 18-B and 18-C ri8-B1 for convenience. The last horizontal 
line on FIG. 18-A is the same line as the first horizontal line on FIG. 18-B^ 
and the last horizontal line on FIG. 18-B is the same line as the first 
horizontal line on FIG. 18-C . By "external clinical system" we mean a 
system used by a health care provider that is supplying data to the 
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exchange system. The external system can also be one that requests 
data from the exchange. This example demonstrates the method by 
which the data would be sent to the exchange. The example illustrates 
the loosely coupled nature of the exchange architecture. Loosely coupled 
systems do not have hard coded linkages between them, but rely instead 
on a communications protocols and standards to achieve their 
associations. 



The five paragraphs beginning at page 48, line 1, and ending at line 20, have 
been amended as follows: 



FIG. 24 provides an example XML document type definition (DTD). 
This DTD is used to describe the message envelope and the payload 
containers transmitted to the system in a "write metadata" transaction. 
FIG. 24 is divided into Figures 24-A and 24-B for convenient viewing. 



FIG. 25 provides an example XML DTD used to describe the data 
transmitted in a "write metadata" transaction. FIG. 25 is divided into 
Figures 25-A through 25-J r25-G1 for convenient viewing. 

FIG. 26 provides an example XML DTD used to describe the data 
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transmitted in "delete metadata" transaction. FIG. 26 is divided into 
Figures 26-A through 26-F f26-Dl for convenient viewing. 

FIG. 27 provides an example XML DTD used to describe the data 
transmitted in "merge metadata" transaction. FIG. 27 is divided into 
Figures 27-A through 27-J r27-Gl for convenience. 

FIG. 28 illustrates the class hierarchies for the entities associated in 
the exchange server for identifying and finding patients, their providers 
and the organizations that have provided treatment. FIG. 28 is divided 
into Figures 28-A and 28-B for convenience. The last horizontal line on 
FIG. 28-A is the same line as the first horizontal line on FIG. 28-B. This 
hierarchy defines the universal person object that establishes patient 
identity in the exchange. Rather than rely on a generated or artificial 
identifier or key, the exchange relies on the rich set of demographic data 
and history that becomes a universal person object. This class hierarchy 
allows the exchange to capture several complex relationships between a 
person and the many attributes that are a part of the person. 

The paragraph beginning at page 50, line 5, and ending at line 10, has been 
amended as follows: 
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In addition to the capability to receive patient demographic data or 
locator information, it is necessary to answer queries that will use the 
correlated and processed data. FIG. 29 describes the mechanism for 
processing a query to find where a patient has been seen and what 
records might be available for that patient. FIG. 29 is a sequence diagram 
describing details of how an external clinical system requests a location 
from the exchange. FIG. 29 is divided into Figures 29-A and 29-B for 
convenience. The last horizontal line on FIG. 29-A is the same line as the 
first horizontal line on FIG. 29-B. 
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